For information there I had 2 PR to upgrade usage to authorize call:

• [Tx ext stage 2: 3/4] use #[pallet::authorize(...)] to migrate unsigned in system: tasks + apply_authorized_call #6325
• [Tx ext stage 2: 4/4] use #[pallet::authorize(...)] to migrate all unsigned in polkadot-sdk #6326

I also think it is actually somewhat a breaking change. Even if the old flow with unsigned transaction is kept, using a different transaction may break indexers and application monitoring the chain through those extrinsics.
It is also why I didn't push it.

IMO validate_unsigned is also ok, this is why I didn't push it, but examples should definitely show authorize call and general transactions flow.

For information there I had 2 PR to upgrade usage to authorize call:

• [Tx ext stage 2: 3/4] use #[pallet::authorize(...)] to migrate unsigned in system: tasks + apply_authorized_call #6325
• [Tx ext stage 2: 4/4] use #[pallet::authorize(...)] to migrate all unsigned in polkadot-sdk #6326

I also think it is actually somewhat a breaking change. Even if the old flow with unsigned transaction is kept, using a different transaction may break indexers and application monitoring the chain through those extrinsics. It is also why I didn't push it.

IMO validate_unsigned is also ok, this is why I didn't push it, but examples should definitely show authorize call and general transactions flow.

Hi @gui1117,

Agreed, these 2 PR's you mentioned complement this one. What is blocking them?

Agreed, these 2 PR's you mentioned complement this one. What is blocking them?

Because I think it is unnecessary breaking change.

In general I don't think we should deprecate ValidateUnsigned, now that the transaction pool is fork-aware there is no need to remove it, the transaction pool was the only reason we wanted to differentiate between inherents and unsigned transactions, now I don't see any reason to remove unsigned transactions.

Every time we deprecate something it involves extra work for everybody using the feature. I don't see it as necessary.

Agreed, these 2 PR's you mentioned complement this one. What is blocking them?

Because I think it is unnecessary breaking change.

In general I don't think we should deprecate ValidateUnsigned, now that the transaction pool is fork-aware there is no need to remove it, the transaction pool was the only reason we wanted to differentiate between inherents and unsigned transactions, now I don't see any reason to remove unsigned transactions.

Every time we deprecate something it involves extra work for everybody using the feature. I don't see it as necessary.

The main concern is that the SDK now needs to maintain multiple mechanisms for achieving the same goal, which increases complexity and makes the codebase harder to maintain and document consistently.

Ideally, there should be a single, recommended way to validate unsigned transactions. That mechanism should be well-maintained and clearly documented.

I agree that the new extension mechanism currently lacks documentation, and requiring runtime developers to explicitly include frame_system::AuthorizeCall is not ideal. It might make sense to enable this extension by default, or alternatively, emit a compilation error if a pallet requires and the extension is not explicitly set in the runtime definition.

I agree that the new extension mechanism currently lacks documentation, and requiring runtime developers to explicitly include frame_system::AuthorizeCall is not ideal. It might make sense to enable this extension by default, or alternatively, emit a compilation error if a pallet requires and the extension is not explicitly set in the runtime definition.

This is hard because frame-executive only require an applyable implementation. The definition of the transaction extension is not accessible by Frame.

Maybe there is a way to make an integrity test.

Note that everytime a pallet defines an extension this extension can also be missed during the runtime configuration.